I don't feel like seeing notifications that I'm not paying attention
to files I haven't touched.

Mostly from -Wsign-compare, -Wformat-truncation, and
-Wformat-overflow; some from -Wmaybe-uninitialized.

This should get things to work somewhat reliably with how I set up
Cygwin.  It may not need the repeated -lstuff options on Linux
systems, but it does on anything with a Windows linker model.

It tries to link with a library it didn't build.  This does not work
terribly well.

I looked up system functions for copy, but those seem to be unique to
C++17.  Removing a file might be done with unlink(), but I don't know
the C API that well, so copying what I did for posix_spawn() it is.

…ization.

…nd-dependent hydrometeor retrieval. (wrf-model#1920)

A background-dependent hydrometeor retrieval scheme for indirect radar reflectivity assimilation

TYPE: New feature

KEYWORDS: Reflectivity assimilation, hydrometeor retrieval

SOURCE: Haiqin Chen (Nanjing University); Tao Sun (NCAR)

DESCRIPTION OF CHANGES:
Problem:
In the original WRFDA use_radar_rhv scheme, the proportion of the snow and graupel is a fixed value that is measured by the ratio of coefficients for snow and graupel. In that case, the same snow mixing ratio and graupel mixing ratio are retrieved from reflectivity data.

Solution:
A background-dependent hydrometer retrieval and assimilation scheme is added to assimilate hydrometeors from reflectivity data. In this new scheme, the proportion of each hydrometeor from reflectivity data is diagnosed from background microphysical states. With this scheme, the contribution of each hydrometeor species to the reflectivity varies widely
in different reflectivity ranges and different heights. Therefore, the retrieved hydrometeors are more reasonable, and better hydrometeor analysis can be obtained from reflectivity assimilation.
References:
Chen, H., Gao, J., Wang, Y., Chen, Y., Sun, T., Carlin, J. and Zheng, Y., 2021. Radar reflectivity data assimilation method based on background‐dependent hydrometeor retrieval: Comparison with direct assimilation for real cases. Quarterly Journal of the Royal Meteorological Society, 147(737), pp.2409-2428.
Chen, H., Chen, Y., Gao, J., Sun, T. and Carlin, J.T., 2020. A radar reflectivity data assimilation method based on background-dependent hydrometeor retrieval: An observing system simulation experiment. Atmospheric research, 243, p.105022.

LIST OF MODIFIED FILES: list of changed files (use `git diff --name-status master` to get formatted list)
M. Registry/registry.var
M. var/da/da_radar/da_radar.f90
M. var/da/da_radar/da_get_innov_vector_radar.inc

TESTS CONDUCTED: 
1. The codes are successfully compiled in Chyenne using the intel fortran.
1. Single-time reflectivity assimilation has been tested in Cheyenne and reasonable results are obtained.

TYPE: new feature

KEYWORDS: lightning data, vertical velocity, pseudo divergence, pseudo water vapor

SOURCE: Zhixiong Chen (zchen@fjnu.edu.cn, Fujian Normal University, China)

DESCRIPTION OF CHANGES:
A new lightning data assimilation scheme has been implemented in the WRFDA. In this lightning DA scheme, the lightning flash rate is first converted to the maximum vertical velocity using an empirical relationship and then expanded to profiles of vertical velocities. The profiles of vertical velocity can be directly assimilated with the control variable of W. Another way is to assimilate pseudo divergence converted from vertical velocity to adjust the Kinematic states. A scheme to assimilate pseudo water vapor retrievals from lightning flash rate observations is also added. In the humidity assimilation scheme, the mixing ratio profiles of pseudo water vapor are retrieved from the locations where a rapid increase in lightning flash rate is detected. 

LIST OF MODIFIED FILES: 
M       Registry/registry.var
M       frame/module_driver_constants.F
M       var/build/da.make
M       var/build/depend.txt
M       var/da/da_control/da_control.f90
M       var/da/da_define_structures/da_allocate_observations.inc
M       var/da/da_define_structures/da_allocate_y.inc
A       var/da/da_define_structures/da_allocate_y_lightning.inc
M       var/da/da_define_structures/da_deallocate_observations.inc
M       var/da/da_define_structures/da_deallocate_y.inc
M       var/da/da_define_structures/da_define_structures.f90
M       var/da/da_define_structures/da_zero_y.inc
A       var/da/da_lightning/da_ao_stats_lightning.inc
A       var/da/da_lightning/da_calculate_grady_lightning.inc
A       var/da/da_lightning/da_check_max_iv_lightning.inc
A       var/da/da_lightning/da_div_profile.inc
A       var/da/da_lightning/da_div_profile_adj.inc
A       var/da/da_lightning/da_div_profile_tl.inc
A       var/da/da_lightning/da_get_innov_vector_lightning.inc
A       var/da/da_lightning/da_jo_and_grady_lightning.inc
A       var/da/da_lightning/da_lightning.f90
A       var/da/da_lightning/da_oi_stats_lightning.inc
A       var/da/da_lightning/da_print_stats_lightning.inc
A       var/da/da_lightning/da_residual_lightning.inc
A       var/da/da_lightning/da_transform_xtoy_lightning.inc
A       var/da/da_lightning/da_transform_xtoy_lightning_adj.inc
M       var/da/da_main/da_wrfvar_top.f90
M       var/da/da_minimisation/da_calculate_grady.inc
M       var/da/da_minimisation/da_calculate_residual.inc
M       var/da/da_minimisation/da_get_innov_vector.inc
M       var/da/da_minimisation/da_get_var_diagnostics.inc
M       var/da/da_minimisation/da_jo_and_grady.inc
M       var/da/da_minimisation/da_minimisation.f90
M       var/da/da_minimisation/da_write_diagnostics.inc
M       var/da/da_obs/da_fill_obs_structures.inc
A       var/da/da_obs/da_fill_obs_structures_lightning.inc
M       var/da/da_obs/da_obs.f90
M       var/da/da_obs/da_obs_sensitivity.inc
M       var/da/da_obs/da_transform_xtoy.inc
M       var/da/da_obs/da_transform_xtoy_adj.inc
M       var/da/da_obs_io/da_final_write_obs.inc
M       var/da/da_obs_io/da_obs_io.f90
M       var/da/da_obs_io/da_read_iv_for_multi_inc.inc
A       var/da/da_obs_io/da_read_obs_lightning.inc
M       var/da/da_obs_io/da_read_omb_tmp.inc
A       var/da/da_obs_io/da_scan_obs_lightning.inc
M       var/da/da_obs_io/da_search_obs.inc
M       var/da/da_obs_io/da_write_iv_for_multi_inc.inc
M       var/da/da_obs_io/da_write_obs.inc
M       var/da/da_setup_structures/da_setup_obs_structures.inc
M       var/da/da_setup_structures/da_setup_obs_structures_ascii.inc
A       var/da/da_setup_structures/da_setup_obs_structures_lightning.inc
M       var/da/da_setup_structures/da_setup_structures.f90
M       var/da/da_statistics/da_analysis_stats.inc
M       var/da/da_statistics/da_statistics.f90
M       var/da/da_test/da_check_xtoy_adjoint.inc
A       var/da/da_test/da_check_xtoy_adjoint_lightning.inc
M       var/da/da_test/da_get_y_lhs_value.inc
M       var/da/da_test/da_test.f90

TESTS CONDUCTED: 
1. Tested it with 3DVar on Cheyenne using the intel compiler.

RELEASE NOTE: 
A lightning data assimilation scheme has been added to assimilate pseudo vertical velocity, divergence fields, or water vapor retrievals from lightning flash rate data.
Chen, Z., Sun, J., Qie, X., Zhang, Y., Ying, Z., Xiao, X., & Cao, D. (2020). A method to update model kinematic states by assimilating satellite-observed total lightning data to improve convective analysis and forecasting. Journal of Geophysical Research: Atmospheres, 125, e2020JD033330. https://doi.org/10.1029/2020JD033330

Bugfix for the lightning DA

TYPE: bug fix

DESCRIPTION OF CHANGES:
There are some bugs in the [PR#1962](wrf-model#1962), which is fixed in this PR.

LIST OF MODIFIED FILES:
M   var/da/da_minimisation/da_get_var_diagnostics.inc
M   var/da/da_statistics/da_analysis_stats.inc

TESTS CONDUCTED: 
1. Tested using the GNU compiler on Derecho.

Removal of redundant code files wrf_status_codes.h, wrf_io_flags.h, io_int_idx_tags.h

…ilently

wrf-model#2125)

This change fixes the warning appearing when calling `configure_new`
with newer versions of Cmake.

TYPE: bug fix

KEYWORDS: cmake, configure

SOURCE: Jakub Lewandowski (University of Leeds)

DESCRIPTION OF CHANGES:
Problem:
When calling `configure_new` script with newer versions of Cmake (3.30.5
in my case) warning appears:

```
CMake Warning (dev) at CMakeLists.txt:5 (enable_language):
  project() should be called prior to this enable_language() call.
This warning is for project developers.  Use -Wno-dev to suppress it.
```

Solution:
This is easily fixable by calling `project()` before `enable_language()`
as the warning suggests.

ISSUE: For use when this PR closes an issue.
n/a

LIST OF MODIFIED FILES: CmakeLists.txt

TESTS CONDUCTED: 
1. Do mods fix problem? How can that be demonstrated, and was that test
conducted?
2. Are the Jenkins tests all passing?

I tested the change on my machine and it solved the issue. As the change
is very minor it should not cause issues for others.

RELEASE NOTE: Fixed CMake dev warning `project() should be called prior
to this enable_language() call` appearing when using `configure_new`
script with some newer versions of Cmake.

…del#2132)

TYPE: bug fix

KEYWORDS: autogeneration, compilation, cmake

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Currently the CMake build system minimum version is limited by the
automated scoping of generated property on certain source files. This in
combination of `CMP0118` requires usage of CMake >3.20

Solution:
Set the generated property at the correct scope for source file usage.
Lower the minimum required version to reflect this change. Note that
CMake 3.18.6 is not used as there are features from 3.19 in use that,
while could be implemented by hand, would take more effort to remove
than the gained benefit.

TESTS CONDUCTED: 
1. Combined with wrf-model#2125, wrf-model#2130, and wrf-model#2131 this was tested on the latest
patch of each unique minor release of CMake since v3.19.8. The full list
of tested versions is as follows:
v3.19.8
v3.20.6
v3.21.7
v3.22.6
v3.23.5
v3.24.4
v3.25.3
v3.26.6
v3.27.9
v3.28.6
v3.29.8
v3.30.5
v3.31.0

RELEASE NOTE: 
Set the generated property on autogen source code explicitly in CMake
and allow for lowered minimum CMake version of v3.19

TYPE: bug fix

KEYWORDS: cmake, flags, optimization

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
To feed initial flags into the cmake build, a toolchain file is used. 

However, for particular build configurations, namely release and debug,
despite the configuration being "Release" and "Debug", respectively, the
corresponding `CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` has the configuration
name capitalized.

Additionally, these initial flags supplement the starting flags and do
not override any inherited flags that CMake automatically appends. This
can cause issues with certain compilers where subsequent flags that
normally should supersede previously listed options are ignored. As an
example, using nvfortran/pgi the following will cause forced
optimization, which is not viable for some files within WRF :

https://forums.developer.nvidia.com/t/nvfortran-reducing-optimation-level-by-multiple-on-does-not-work/191825

https://forums.developer.nvidia.com/t/how-to-override-pgccs-optimization-flag/136275

Finally, certain files do not have optimization overridden even if it
were to work correctly

Solution:
Ensure correct variable name in toolchain file to provide initial
starting flags, and wipe CMake-injected release flags to avoid
significant deviation from provided optimization flags. Add proper
directory scope to files that need these reduced optimizations.


TESTS CONDUCTED: 
1. Tested with CMake build on Derecho selecting nvhpc/pgi compiler
stanzas

RELEASE NOTE: Override CMake-injected optimization flags in favor of the
flags set by the build system and provided stanza information.

TYPE: enhancement

KEYWORDS: cmake, wrfplus

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current CMake build does not build the WRF PLUS core configuration

Solution:
Add the necessary source files to compile WRF PLUS. WRF binary will
still be created, but a symlink to `wrfplus.exe` will also be created
for backward compatibility

TYPE: enhancement, no impact

KEYWORDS: manage_externals, some physics for tropical suite

SOURCE: internal

DESCRIPTION OF CHANGES:
Add the use of manage_externals tool to access physics in
[MMM-physics](https://github.com/NCAR/MMM-physics) repository. The
physics we access are part of the 'tropical' suite: YSU PBL, revised MM5
surface layer, WSM6 microphysics, and new Tiedtke scheme. It also
accesses GWDO option 1 routine. These modules have been residing in
phys/physics_mmm/ in 4.6. Instead of copied files in this directory, we
now use manage_externals to access these modules from MMM-physics
repository.

Will need to update the tags specified in Externals.cfg before final
release.

LIST OF MODIFIED FILES: 
A       arch/Externals.cfg
M       phys/Makefile
D       phys/physics_mmm/bl_gwdo.F90
D       phys/physics_mmm/bl_ysu.F90
D       phys/physics_mmm/cu_ntiedtke.F90
D       phys/physics_mmm/module_libmassv.F90
D       phys/physics_mmm/mp_radar.F90
D       phys/physics_mmm/mp_wsm6.F90
D       phys/physics_mmm/mp_wsm6_effectRad.F90
D       phys/physics_mmm/sf_sfclayrev.F90
A       tools/manage_externals/

TESTS CONDUCTED: 
1. Successfully compiled the code on Derecho.
2. Are the Jenkins tests all passing?

RELEASE NOTE: Add manage_externals tool to access physics modules in
MMM-physics git repository.

TYPE: bug fix

KEYWORDS: cmake, mpi, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The `arch/configure_reader.py` does the job of parsing, organizing, and
sanitizing input from configuration stanzas into a CMake toolchain file
which can then be used to inform the build about which compilers, flags,
and options to use.

Occasionally, stanzas fields inject flags into a compiler or other
command field (like `DM_FC`) so that the actual command is a command +
flags. Part of the `arch/configure_reader.py` organization is breaking
these up into separable sections automatically. With the example of
`DM_FC = mpif90 -f90=gfortran` (`$(SFC)` already expanded) this _should_
be broken into `DM_FC = mpif90` and `DM_FC_FLAGS = -f90=gfortran`.
Currently, the `*_FLAGS` field when split out for certain keys in a
stanza is not populated due to using the wrong index from the Python
`str.partition()` call.

Secondly, when these fields are actually provided to CMake compilation
breaks for MPI specifically. Since the MPI "compilers" are wrappers,
they are then interrogated for the underlying flags and options meaning
further adding the flags back into compilation results in things like
`gfortran <all the other flags> -f90=gfortran`. This is incorrect, and
instead the flags should be provided to the MPI flags used during
wrapper interrogation on a per-language basis. Furthermore, for certain
MPI implementations supplying any flags renders the query command (e.g.
`-show`, `-showme`, or `-compileinfo`) useless. For instance, OpenMPI
`mpif90 -f90=gfortran -show` only outputs `gfortran -f90=gfortran` which
is also wrong.

Solution:
1. The Python call to split the fields should take the actual values
2. MPI flags per language should be supplied to the interrogation flags
`MPI_<LANG>_COMPILER_FLAGS` if needed
3. The `FindMPI` module already feeds in the underlying compiler
specification for wrappers that support it so flags like `-f90=$(SFC)`
should be filtered out from `DM_*_FLAGS` before being written to the
`wrf_config.cmake` toolchain file

TESTS CONDUCTED: 
1. Flags in specific command fields are now split and appearing in the
`wrf_config.cmake` file
2. MPI compilation works with compiler specification filtered out but
correct underlying compiler still selected even when multiple compilers
are in the same environment (note: this was the original behavior but
now is deliberate)

TYPE: bug fix

KEYWORDS: double precision, configuration, make, cmake

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Currently, the source code has multiple preprocessor definitions for
controlling double precision usage (1). Likewise, there are multiple
parameter definitions in the IO code for the `WRF_REAL` value (2).

Examples of (1) :
```
#if ( RWORDSIZE == 8 )
#if ( RWORDSIZE == DWORDSIZE )
#if ( DWORDSIZE == 8 && RWORDSIZE == 8 )
```

Because there is no definitive define for querying double precision, it
has been left as an exercise to the contributor to formulate an adequate
conditional. While the above and other such forms work, they are not
consistent and can be confusing as to the intent.

Examples of (2) in a directory with option `-r8` :
```bash
 grep -RiE "WRF_REAL.*=.*[0-9]+" | sort -u
# original version
external/ioapi_share/wrf_io_flags.h:      integer, parameter  :: WRF_REAL                             = 104
external/io_grib1/io_grib1.f90:      integer, parameter  :: WRF_REAL                             = 104
external/io_grib_share/io_grib_share.f90:      integer, parameter  :: WRF_REAL                             = 104
external/io_int/diffwrf.f:      integer, parameter  :: WRF_REAL                             = 104
external/io_int/io_int.f:      integer, parameter  :: WRF_REAL                             = 105
external/io_netcdf/wrf_io.f:      integer, parameter  :: WRF_REAL                             = 104
frame/module_io.f90:      integer, parameter  :: WRF_REAL                             = 105
frame/module_quilt_outbuf_ops.f90:      integer, parameter  :: WRF_REAL                             = 105
# modified version
# inc/wrf_io_flags.h:      integer, parameter  :: WRF_REAL                             = 105
main/real_em.f90:      integer, parameter  :: WRF_REAL                             = 105
share/input_wrf.f90:      integer, parameter  :: WRF_REAL                             = 105
share/mediation_integrate.f90:      integer, parameter  :: WRF_REAL                             = 105
share/output_wrf.f90:      integer, parameter  :: WRF_REAL                             = 105
share/track_input.f90:      integer, parameter  :: WRF_REAL                             = 105
share/wrf_bdyin.f90:      integer, parameter  :: WRF_REAL                             = 105
share/wrf_bdyout.f90:      integer, parameter  :: WRF_REAL                             = 105
share/wrf_tsin.f90:      integer, parameter  :: WRF_REAL                             = 105
var/da/da_main/da_update_firstguess.inc:  wrf_real=104
```

Across many different preprocessed files, there appears to be two values
of `WRF_REAL` which could lead to undesired behavior when interfacing
between different sections of code. This issue arises from the `sed`
command in `external/ioapi_share/makefile` where `wrf_io_flags.h` is
changed in the `inc/` folder _only_, and thus anything including
`external/ioapi_share` first has one definition whilst anything
including `inc/` has the changed value.

While (2) may seem like an entirely separate problem from (1) they are
interrelated. `wrf_io_flags.h` already partially contains the necessary
logic to control whether to use `104` or `105` when double precision
promotion is requested. The current logic is not being used correctly
fully as it uses a totally different (and undefined) form of double
precision query :
```fortran
#ifdef PROMOTE_FLOAT
  integer, parameter :: WRF_FLOAT = WRF_DOUBLE
#else
  integer, parameter :: WRF_FLOAT = WRF_REAL
#endif
```
The end result will always be `WRF_FLOAT = WRF_REAL` regardless of `-r8`
option since `PROMOTE_FLOAT` is not defined anywhere in the
configuration / compilation logic. However, `WRF_FLOAT` _happens to be
used correctly_ since the `sed` rewrite has changed `WRF_REAL` to `105`
(effectively the same as `WRF_FLOAT = WRF_DOUBLE`). This only works
because `WRF_FLOAT` is exclusively used only in files that access the
`inc/wrf_io_flags.h` rewritten file and not the
`external/ioapi_share/wrf_io_flags.h` one. Furthermore, aside from
`io_int.F`, no code that contains the `105` value utilizes `WRF_REAL`
```bash
# Looking for any incorrect usage of WRF_FLOAT in files with 104 value
# we're really only concerned with unique statements of computational code
grep -RiEl "WRF_REAL.*=.*104" | sort -u  | xargs -i grep -iH WRF_FLOAT {} | sort -u
external/ioapi_share/wrf_io_flags.h:      integer, parameter  :: WRF_FLOAT=WRF_DOUBLE
external/io_grib1/io_grib1.f90:      integer, parameter  :: WRF_FLOAT=WRF_REAL
external/io_grib_share/io_grib_share.f90:      integer, parameter  :: WRF_FLOAT=WRF_REAL
external/io_int/diffwrf.f:      integer, parameter  :: WRF_FLOAT=WRF_REAL
external/io_netcdf/wrf_io.f:      integer, parameter  :: WRF_FLOAT=WRF_REAL
# No usage of bad value, only the include declaration shows up
```

```bash
# Look for usage of WRF_REAL where its value has been changed to 105 thus
# leading to ambiguous definitions
# Exclude declarations for brevity 
grep -RiEl "WRF_REAL.*=.*105" | sort -u  | xargs -i grep -iH WRF_REAL {} | sort -u | grep -vE "integer, parameter[ ]*:: WRF_"
external/io_int/io_int.f:            CALL wrf_message('io_int.F90: ext_int_read_field: types other than WRF_REAL not supported yet')
external/io_int/io_int.f:  IF      ( FieldType .EQ. WRF_REAL .OR. FieldType .EQ. WRF_DOUBLE) THEN
external/io_int/io_int.f:          IF      ( FieldType .EQ. WRF_REAL ) THEN
external/io_int/io_int.f:    IF      ( FieldType .EQ. WRF_REAL ) THEN
# These are character strings
main/real_em.f90:      IF ( config_flags%auxinput1_inname(1:8) .NE. 'wrf_real' ) THEN
share/input_wrf.f90:              ( config_flags%auxinput1_inname(1:8) .EQ. 'wrf_real' ) ) ) THEN
```

Solution:
To reduce the overall complexity of various define constructs _and_ IO
inconsistencies a singular define `DOUBLE_PRECISION` can be introduced
specifically meant to inform sections of code whether double precision
promotion has been requested.

Adding "one more define" may not sound appealing at first, but it does
carry some benefits :
* Firstly, it does not require the user to hard code values of `4` or
`8` for single or double precision, respectively, where those are
already defined by `NATIVE_RWORDSIZE` and `DWORDSIZE`.

* Furthermore, rather than use `#if (RWORDSIZE == DWORDSIZE)` logic can
be simplified to a more coherent statement of `#ifdef DOUBLE_PRECISION`
which is more readable and better understood in intent.

* Finally, reducing duplication of defines to do the same thing is good
practice _and_ limiting defines to control one thing only avoiding
co-opting for multiple roles is *also* good practice. The first part
sounds counter to a new define but `RWORDSIZE` and `DOUBLE_PRECISION`
serve two different functions - the former to tell us the numeric size
of real data in bytes and the latter to tell us if alternate logic
should be used. An alternative solution to only use a single define
would be to have `DOUBLE_PRECISION` control an `rkind` setting
`RWORDSIZE` much like `kind_phys` for ccpp

For areas where `WRF_REAL` was used with a value of `105` when `-r8` is
used (`io_int.F`), to maintain previous behavior the value should be
changed to `WRF_FLOAT`. Instead of using `sed` to rewrite the file,
`#ifdef PROMOTE_FLOAT` will use the valid `DOUBLE_PRECISION` define to
switch control of `WRF_FLOAT` to `WRF_DOUBLE` if defined, or `WRF_REAL`
if not.

For the CMake build, `DOUBLE_PRECISION` needs to be added to the
defines. No other changes necessary.

To reduce the complexity of these changes, `wrf_io_flags.h` is still
copied out to `inc/`, this may be addressed separately.

TESTS CONDUCTED: 
1. Single and double precision builds should compile without issue and
have effectively the same logic as before

TYPE: new feature, enhancement

KEYWORDS: hydro, reservoir, reach lakes, namelist style guide

SOURCE: Soren Rasmussen and Ryan Cabell, NSF NCAR, internal

DESCRIPTION OF CHANGES:
* Add lake_opt to namelist, reservoirs to own nlist
- Add (integer) to &hydro_nlist: 0 [lakes off], 1 [level pool], or 2
[passthrough], or 3 [reservoir DA]

  - turning lakes off (lake_option=0) will disable lakes even if
    route_lake_f is supplied, or outlake is turned on.

  - Reservoir DA will not be used unless lake_option=3, even if all
    other required namelist options are present

  - Reset lake_opt from 3 to 1 after setting DA flag

* Reservoir options have been moved from &hydro_nlist to
  &reservoir_nlist

   - This will make it easier to isolate / compose namelist files

   - If lake_option is not equal to 3, &reservoir_nlist won't be read,
     meaning it can be completely removed for applications that don't
     need it

   - Use reasonable lake_option default when not specified
   - Update testing namelists

* Forcing variables names that have been added to namelist.hrldas

* Reach Lakes: support for lakes (reservoirs) in non-UDMP reach-based
routing, restoring functionality that was in WRF-Hydro version 5.1.1

* Style guide cleanup
  - Remove unneeded return statements
  - Remove file header
  - Tabs to spaces
  - Trailing whitespace cleanup
  - MPI Capitalization

Problem: WRF-Hydro developments need to be ported over for future
release

LIST OF MODIFIED FILES:
```
M       hydro/CPL/WRF_cpl/module_wrf_HYDRO.F90
M       hydro/CPL/WRF_cpl/module_wrf_HYDRO_downscale.F90
M       hydro/CPL/WRF_cpl/wrf_drv_HYDRO.F90
M       hydro/Data_Rec/module_RT_data.F90
M       hydro/Data_Rec/module_gw_gw2d_data.F90
M       hydro/Data_Rec/module_namelist.F90
M       hydro/HYDRO_drv/module_HYDRO_drv.F90
M       hydro/IO/netcdf_layer.F90
M       hydro/MPP/CPL_WRF.F90
M       hydro/MPP/module_mpp_GWBUCKET.F90
M       hydro/MPP/module_mpp_ReachLS.F90
M       hydro/MPP/mpp_land.F90
M       hydro/OrchestratorLayer/config.F90
M       hydro/Routing/Noah_distr_routing.F90
M       hydro/Routing/Reservoirs/Level_Pool/module_levelpool.F90
M       hydro/Routing/Reservoirs/Level_Pool/module_levelpool_properties.F90
M       hydro/Routing/Reservoirs/Persistence_Level_Pool_Hybrid/module_persistence_levelpool_hybrid.F90
M       hydro/Routing/Reservoirs/RFC_Forecasts/module_rfc_forecasts.F90
M       hydro/Routing/module_GW_baseflow.F90
M       hydro/Routing/module_HYDRO_io.F90
M       hydro/Routing/module_HYDRO_utils.F90
M       hydro/Routing/module_NWM_io.F90
M       hydro/Routing/module_RT.F90
M       hydro/Routing/module_UDMAP.F90
M       hydro/Routing/module_channel_routing.F90
M       hydro/Routing/module_date_utilities_rt.F90
M       hydro/Routing/module_gw_gw2d.F90
M       hydro/Routing/module_lsm_forcing.F90
M       hydro/Routing/module_reservoir_routing.F90
M       hydro/nudging/module_date_utils_nudging.F90
M       hydro/nudging/module_nudging_io.F90
M       hydro/nudging/module_nudging_utils.F90
M       hydro/nudging/module_stream_nudging.F90
M       hydro/template/HYDRO/hydro.namelist
M       hydro/template/NoahMP/namelist.hrldas
M       hydro/utils/module_hydro_stop.F90
```

TESTS CONDUCTED: 
1. Currently testing hydro's WRF testcase on new CMake and old Makefile
build systems. **PR will be draft until fully tested.**
2. Are the Jenkins tests all passing? Yes
```
    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 23           24
    Number of Builds       : 60           57
    Number of Simulations  : 158           150        0
    Number of Comparisons  : 95           86        0

    Failed Simulations are: 
    None
    Which comparisons are not bit-for-bit: 
    None
```

RELEASE NOTE: 
hydro updates: In `hydro.namelist` adding lake_opt to namelist,
reservoirs to own namelist. Support for lakes (reservoirs) in non-UDMP
reach-based routing added and some style guide cleanup completed.

…SGS urban category. (wrf-model#2153)

TYPE: bug fix

KEYWORDS: LCZ, USGS

SOURCE: Lukas Pilz (Heidelberg University)

DESCRIPTION OF CHANGES:
Problem:
As shown in wrf-model#2152, for USGS data the wrfinput LU_INDEX field has major differences to the met_em LU_INDEX field. Cells in LU_INDEX which have LCZ categories (>30) were overwritten with the default USGS urban category (1) where FRC_URB2D > 0.5.

Solution:
Add a check similar to the MODIS case above.

ISSUE:
Fixes wrf-model#2152 

LIST OF MODIFIED FILES: 
M    dyn_em/module_initialize_real.F

TESTS CONDUCTED: 
1. Did local tests, the only differences between wrfinput and met_em which remain are changing LU_INDEX 28 to 16, which is a water body redesignation as to my knowledge.
2. Jenkins tests have passed.

RELEASE NOTE: Bug fix for wrfinput where LCZ urban cells in LU_INDEX were overwritten with default USGS urban category.

TYPE: new feature

KEYWORDS: microphysics, physics, rainfall, warm rain, cloud water

SOURCE: Robert Conrick (U. of Washington); robert.conrick@gmail.com

DESCRIPTION OF CHANGES:
This is the release of the RCON microphysics scheme, the intent of which is to improve warm rain representation within the Thompson-Eidhammer scheme.

LIST OF MODIFIED FILES: 
        modified:   Registry/Registry.EM_COMMON
        modified:   Registry/registry.var
        modified:   dyn_em/solve_em.F
        modified:   phys/Makefile
        modified:   phys/module_microphysics_driver.F
        new file:   phys/module_mp_rcon.F
        modified:   phys/module_physics_init.F

The code has passed the regression tests.

RELEASE NOTE: 
Release of the RCON Microphysics package into WRF, which improves upon the warm rain representation of the Thompson-Eidhammer scheme.

RCON is based heavily on the Thompson-Eidhammer scheme with a couple significant changes that improve upon the code in module_mp_rcon.F to generate more realistic rainfall during warm rain events with additional benefits for cold rain, especially warm processes during cold rain events.

Among the most significant changes for rain productions are 1) the use of a wider cloud water DSD of lognormal shape instead of the gamma DSD used by the Thompson-Eidhammer parameterization and 2) enhancement of
the cloud-to-rain autoconversion parameterization to accommodate the new shape. The changes here also allow for sedimentation of cloud water within the lowest model layer, which effectively creates a drizzle mode in the scheme.

Accompanying published reference: 
Conrick, R., C. F. Mass, and L. McMurdie, 2023: Improving Simulations of Warm Rain in a Bulk Microphysics Scheme. Mon. Wea. Rev., 152, 169-185, https://doi.org/10.1175/MWR-D-23-0035.1.

…odel#2158)

TYPE: text only

KEYWORDS: README.namelist, adaptive time step

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Definitions for a few adaptive time step-relative variables in README.namelist weren't comprehensible.

Solution:
Modified the wording to make more sense

LIST OF MODIFIED FILES: 
M   run/README.namelist

TYPE: enhancement

KEYWORDS: cmake, chem, kpp

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
Current CMake build does not build chem or chem+kpp configurations

Solution:
Build kpp and associated tools, and cmake commands to facilitate
simplified logic of the `configure_wkc` and `compile_wkc` scripts. As
with all CMake builds, all auto-generated source code is placed in the
out-of-source build directory.

Notable differences to make build :
* Use of Bison instead of Yacc as it is more easily accessible for
install and usage as well as backward compatible
* Allow `-j N` parallel jobs to generate KPP sources up to a limit
* Use KPP-generated source file original names (not renamed to
`module_kpp_*`
* Pass `tuv_kpp` a directory to locate where include file is to be
generated, and allow control of file IO mode*
* Allow integration decomp rewrite to specify file locations rather than
hard-coded*
* `registry` uses `-DWRF_CHEM` and `-DWRF_KPP` defines passed at command
line instead of `getenv()` to match all other options*


*Affects make build in subtle ways but do not change user instructions

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       chem/CMakeLists.txt
A       chem/KPP/CMakeLists.txt
M       chem/KPP/compile_wkc
A       chem/KPP/kpp/kpp-2.1/CMakeLists.txt
A       chem/KPP/util/wkc/CMakeLists.txt
M       chem/KPP/util/wkc/gen_kpp.c
M       chem/KPP/util/wkc/protos_kpp.h
M       chem/KPP/util/wkc/tuv_kpp.c
A       chem/KPP/util/write_decomp/CMakeLists.txt
M       chem/KPP/util/write_decomp/Makefile
M       chem/KPP/util/write_decomp/integr_edit.c
M       chem/chem_driver.F
M       tools/CMakeLists.txt
M       tools/data.h
M       tools/registry.c

TESTS CONDUCTED: 
1. Reproduction of chem and chem+kpp regtests with cmake is possible now

RELEASE NOTE: 
CMake Chem and Chem+KPP Build

TYPE: bug fix

KEYWORDS: snow albedo, soil timestep, glacier heat capacity

SOURCE: Cenlin He (NCAR)

DESCRIPTION OF CHANGES:
Bug fixes for the following three parts:
1. allow BATS snow albedo scheme for nighttime snow aging: NCAR/ccpp-physics#1091
2. fix the potential leakage caused by calculate_soil variable during parallelization: NCAR/noahmp#136
3. fix the missing of HCPCT output for glacier points: NCAR/noahmp#141

LIST OF MODIFIED FILES: only Noah-MP source code is changed in Noah-MP GitHub.
phys/noahmp

TESTS:
The changes have passed the regression tests.

RELEASE NOTE: Noah-MP bug fixes for (1) allowing BATS snow albedo scheme for nighttime snow aging, (2) the potential leakage caused by calculate_soil variable during parallelized run, (3) the missing of HCPCT output for glacier points.

This replaces the original (non submodule) MYNN with the public-facing
MYNN-EDMF submodule, which will the central point of development for the
MYNN-EDMF in WRF, MPAS, and CCPP.

TYPE: bug fix, enhancement, and new feature

KEYWORDS: refactored, submodule, MYNN-EDMF

SOURCE: Joseph Olson (NOAA/GSL)

DESCRIPTION OF CHANGES:

1. Submodule implementation pointing to
https://github.com/NCAR/MYNN-EDMF/
2. This is a refactored scheme (now k-only) which is called from a new
driver derived heavily from the MPAS driver.
3. The module names changed from *_mynn_* to *_mynnedmf_* to resolve a
version conflict in MPAS.
4. This version carries many modification that originated in FV3-related
development for RRFSv1, but it has since been tuned to better perform in
MPAS and WRF, unlike previous versions of the MYNN. The list of
modifications are fairly extensive but the most dycore-sensitive parts
of the MYNN are related to the subgrid clouds. From now on, all minor
commits are captured in the public-facing submodule repository and the
submodule will be updated in WRF at a lower frequency (probably every 6
months or so).

LIST OF MODIFIED FILES: 
M       .gitmodules
M       Makefile
M       Registry/Registry.EM_COMMON
M       clean
M       dyn_em/module_first_rk_step_part1.F
M       main/depend.common
A       phys/MYNN-EDMF
M       phys/Makefile
D       phys/module_bl_mynn.F
D       phys/module_bl_mynn_common.F
D       phys/module_bl_mynn_wrapper.F
M       phys/module_pbl_driver.F
M       phys/module_physics_init.F

TESTS CONDUCTED: 
1. The submodule itself has been tested in both WRF and MPAS for several
months now in NOAA-GSL realtime systems and case study tests, passing
all of our newly designed regression tests.
2. Has been compiled and run with intel and gnu compilers on Jet and
Hera.
3. Are the Jenkins tests all passing?

RELEASE NOTE: Submodule implementation of the MYNN-EDMF
(https://github.com/NCAR/MYNN-EDMF). The module names changed from
*_mynn_* to *_mynnedmf_* to resolve a version conflict in MPAS. This
version was originally developed within FV3/CCPP for RRFSv1, but has
been refactored (to a k-only scheme) resulting in a speed-up of about
10-15% and it has since been tuned to better perform in MPAS and WRF
compared to previous versions which were primarily developed for use in
FV3.

…rf-model#2120)

TYPE: bug fix

KEYWORDS: tke-epsilon-tpe, PBL, stability functions

SOURCE: Andrea Zonato, Royal Netherlands Meteorological Institute (KNMI)

DESCRIPTION OF CHANGES:
Problem:
The stability functions at the surface (phim,phieps) for calculating the boundary values of tke and its dissipation rate in the tke-epsilon-tpe PBL scheme [Zonato et al., 2022](https://doi.org/10.1175/MWR-D-21-0299.1) does not include the correction by z0.

Solution:
Pass the correct stability functions, calculated in module_sf_sfclayrev.F

LIST OF MODIFIED FILES:
phys/module_bl_keps.F
phys/module_pbl_driver.F

TESTS CONDUCTED: 
The Jenkins tests are all passing.

RELEASE NOTE: 
The similarity stability functions phim and phieps, necessary for calculating the surface values of tke and dissipation rate in the tke-epsilon-tpe PBL scheme [Zonato et al., 2022](https://doi.org/10.1175/MWR-D-21-0299.1) have been updated considering the correction term accounting for the roughness length z0. No relevant differences are found in temperature, wind speed, and humidity. Regarding turbulence variables, the stable case has just negligible differences, while the unstable case shows higher values of TKE and dissipation rate and lower values of temperature variance.

TYPE: new feature

KEYWORDS: data assimilation, incremental analysis update

SOURCE: Min Chen of IUM/CMA and internal

DESCRIPTION OF CHANGES:
Add incremental analysis update capability. In the DA code, code is
added to write out analysis increments for all variables in WRF netCDF
format using auxiliary history output stream #5. In the model, analysis
increments are divided by the number of time steps in a specified time
window and added to the model similar to physics tendencies. The input
stream for the model is 15. The capability is turned on by adding iau =
1 and iau_time_window_sec in &time_control. For example:

```
 auxinput15_inname                   = "wrfiauinp_d01"
 io_form_auxinput15                  = 2
 auxinput15_interval                 = 360,
 iau                                 = 1
 iau_time_window_sec                 = 3600.
```
LIST OF MODIFIED FILES: 
M       Registry/Registry.EM_COMMON.var
M       Registry/Registry.wrfvar
M       Registry/registry.em_shared_collection
A       Registry/registry.iau
M       dyn_em/module_em.F
M       dyn_em/module_first_rk_step_part2.F
M       phys/module_physics_addtendc.F
M       var/build/da.make
M       var/build/depend.txt
M       var/da/da_main/da_solve.inc
M       var/da/da_main/da_wrfvar_io.f90
M       var/da/da_main/da_wrfvar_top.f90
A       var/da/da_main/da_write_anaincrements.inc
M       var/da/da_transfer_model/da_transfer_xatowrf.inc

TESTS CONDUCTED: 
The Jenkins tests have passed.

RELEASE NOTE: This PR adds an incremental analysis update capability. In
the DA code, code is added to write out analysis increments for all
variables in WRF netCDF format using auxiliary history output stream #5.
In the model, analysis increments are divided by the number of time
steps in a specified time window and added to the model similar to
physics tendencies. The input stream for the model is 15. The capability
is turned on by adding iau = 1 and iau_time_window_sec in &time_control.
The way the increments are added to the model is similar to what
described by the paper by Chen et al.
(https://doi-org.cuucar.idm.oclc.org/10.1175/WAF-D-22-0127.1).

TYPE: bug fix

KEYWORDS: cmake, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
PR wrf-model#2144 added a new microphysics file `phys/module_mp_rcon.F` which
only added it to the make build

Solution:
Add new RCON file to CMake build

TESTS CONDUCTED: 
1. Develop branch at merge of wrf-model#2144 fails to build CMake build. These
changes fix the build issues

TYPE: bug fix

KEYWORDS: Memory Leaks

SOURCE: Charlie Li - Software developer from lakes environmental Canada

DESCRIPTION OF CHANGES:
Problem:
Memory leaks are detected in wrf_timeseries.F and start_em.F when use
PGI option:
-g -O0 -traceback -Mchkptr -Mbounds -Ktrap=fp -Msave -tp=px
It will failed for: "0: ALLOCATE: array already allocated"

1. In dyn_em/start_em.F, dz8w is allocated, but not deallocated.
2. In share/wrf_timeseries.F, two arrays, earth_u_profile and earth_v_profile, are allocated without being deallocated when time series is not computed.

Solution:
Calls to deallocate the array dz8w is added in start_em.F, and move the return statement before array allocation in wrf_timeseries.F.

LIST OF MODIFIED FILES: 
M     share/wrf_timeseries.F
M     dyn_em/start_em.F

TESTS CONDUCTED: 
The Jenkins tests are all passing.

RELEASE NOTE: This PR fixed memory leaks related to arrays being allocated without being deallocated in start_em and time series calculation subroutines.

TYPE: bug fix

KEYWORDS: crash, access violation error

SOURCE: Charlie Li, software developer from lakes environmental, Canada

DESCRIPTION OF CHANGES:
Problem:
WRF crashed for access violation frequently, due to the change made in
PR wrf-model#1991 when namelist.input has sf_urban_physics = 0 and bl_pbl_physics = 1. Because those arrays from urban models are always available, but their memories are not available if the urban option is not turned on. This causes the access violation in module_bl_ysu.F 

Solution:
The fix is actually using v4.5 logic to check on the flag 'flag_bep' before using the arrays.

LIST OF MODIFIED FILES: 
phys/module_bl_ysu.F

TESTS CONDUCTED: 
The Jenkins tests are all passing.

RELEASE NOTE: This PR fixes a access violation error when a PGI compiler is used with urban variables in module_bl_ysu.F when urban option is turned off and the memories of those arrays are not available.

… displacements overflow. (Fix for wrf-model#2156) (wrf-model#2157)

Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent
displacements overflow.

TYPE: bug fix

KEYWORDS: prevent displacements overflow in MPI_Gatherv() and
MPI_Scatterv() operations

SOURCE: Benjamin Kirk & Negin Sobhani (NSF NCAR / CISL)

DESCRIPTION OF CHANGES:
Problem:
The MPI_Gatherv() and MPI_Scatterv() operations require integer
displacements into the communications buffers. Historically everything
is passed as an MPI_CHAR, causing these displacements to be larger than
otherwise necessary. For large domain sizes this can cause the
displace[] offsets to exceed the maximum int, wrapping to negative
values.

Solution:
This change introduces additional error checking and then uses the
function MPI_Type_match_size() (available since MPI-2.0) to determine a
suitable MPI_Datatype given the input *typesize. The result then is that
the displace[] offsets are in terms of data type extents, rather than
bytes, and less likely to overflow.

ISSUE: Fixes wrf-model#2156 

LIST OF MODIFIED FILES: 
M       frame/collect_on_comm.c

TESTS CONDUCTED: 
Failed cases run now.

RELEASE NOTE: 
Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent
displacements overflow.

…rf-model#2133)

TYPE: bug fix/enhancement

KEYWORDS: wrf, wrfv4, restart, output streams

SOURCE: James Ruppert (University of Oklahoma)

DESCRIPTION OF CHANGES:
Problem:
When running WRF from as a restart, the option write_hist_at_0h_rst would only apply to the default history stream. Now, when this option is set to true, it will also apply to special user-defined streams. This is required to maintain a consistent number of output time steps per file with multiple time steps writing to a single file, which is often preferred for multiple-day runs.

Solution:
Added an additional loop over history streams with CALL med_hist_out when the following condition is met:
IF ( (config_flags%restart) .AND. ( currTime .EQ. startTime ) .AND. (config_flags%write_hist_at_0h_rst ))

LIST OF MODIFIED FILES:
share/mediation_integrate.F

TESTS CONDUCTED: 
1. Verified that this change works: when option is set to true, history write-out at first time step of a restart now applies to both the default history stream and a user-defined stream (tested with stream 7).
2. The Jenkins tests are all passing.

RELEASE NOTE:
When the namelist option write_hist_at_0h_rst is set to .true. under &time_control, history write-out will now be conducted for the first time step for both the 0th stream (wrfout* files) and any special user-defined streams being implemented.

TYPE: new feature

KEYWORDS: UFS Double Moment Microphysics scheme (UDM)

SOURCE: Songyou Hong via internal

DESCRIPTION OF CHANGES:
The new microphysics option is based on 7-class WDM7 with revision and improvements and will be mp_physics=27.

LIST OF MODIFIED FILES: 
M       Registry/Registry.EM_COMMON
M       phys/Makefile
M       phys/module_microphysics_driver.F
M       phys/module_physics_init.F
M       phys/module_mp_udm.F

TESTS CONDUCTED: 
1. Compilation on derecho Cray Intel (ftn) seems to need -O2.
2. squall2d_x test case runs OK.
3. The Jenkins tests are all passing.

RELEASE NOTE: An new microphysics, UFS Double Moment (UDM), 7-class microphysics from Songyou Hong is added (mp_physics=27). UDM mp largely adopts microphysical processes in WDM7, but with bug fixes or revisions
based on literature and accumulated realism. UDM mp utilizes the in-cloud microphysics concept (Kim and Hong 2018), with the addition of water-friendly aerosols for CCN initialization. Semi-lagrangian sedimentation of Juang and Hong (2010) is also re-configured for computational efficiency and numerical accuracy. All production terms are optimized by introducing a cloud-top definition for hydrometeors.

…rf-model#2063)

TYPE: bug fix

KEYWORDS: precipitation, tipping bucket, nudging, spectral nudging, analysis nudging, grid nudging, regional climate, dynamical downscaling, downscaling

SOURCE: Tanya Spero (U.S. EPA)

DESCRIPTION OF CHANGES:
Problem:
Several processes in WRF are currently triggered at periodic intervals
(such as reading/writing files and managing certain bookkeeping
processes). Some of those processes had been coded to identify those
time triggers by referencing a variable that contains the time elapsed
since the model simulation was initialized. That variable, XTIME, is a
Fortran single-precision real variable that counts the number of elapsed
minutes since initialization. However, single-precision real numbers
become imprecise (i.e., cannot accurately resolve "whole" numbers) after
they exceed 2^24, which is 16,777,216. In long simulations, that occurs
just before 32 years of simulation period.

Solution:

Two new variables are introduced based on existing variable CURR_SECS2: CURR_SECS2_R8, and double precision version of CURR_SECS2, to address bucket tipping and CURR_MINS2, based on CURR_SECS2_R8, to address issues in nudging code.

LIST OF MODIFIED FILES: 
M     phys/module_diag_misc.F
M     dyn_em/module_first_rk_step_part1.F 
M     dyn_em/solve_em.F,
M     phys/module_fdda_psufddagd.F
M     phys/module_fdda_spnudging.F,
M     phys/module_fddagd_driver.F
M     wrftladj/wrftladj/solve_em_ad.F

TESTS CONDUCTED: 
1. Modified code has been tested extensively using a long simulation (using a restart at more than 31 years into the simulation) with WRFv4.5.1 and with shorter (3-day) simulations using WRFv4.6. 
2. The Jenkins tests are all passing.

RELEASE NOTE: Corrected algorithms in the tipping bucket for precipitation and in the nudging routines to adjust for imprecision in single-precision real numbers exceeding the resolvable values in long (>23-year) continuous simulations.

…el#2165)

TYPE: enhancement, no impact, text only

KEYWORDS: vertical coordinate, namelist

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current namelist.input file only has dzstretch_s. To properly use the auto_levels_opt, dzstretch_u and dzbot should be considered.

Solution:
Add dzstretch_u and dzbot in the namelist. Parameters based on UG.

LIST OF MODIFIED FILES: 
M       test/em_real/namelist.input

TESTS CONDUCTED: 
The Jenkins tests have passed.

RELEASE NOTE: Add dzstretch_u and dzbot in namelist.input. Users are advised to check UG for other parameters to use.

wrf-model#2185)

TYPE: bug fix

KEYWORDS: WRF-Chem, dry air density

SOURCE: NOAA GSL, Alexander Ukhov (KAUST)

DESCRIPTION OF CHANGES:
Problem:
It was found that dry air density was miscalculated.

Solution:
Removed unnecessary factor. Simulations before and after did not show any significant difference, as expected.

LIST OF MODIFIED FILES:
M chem/module_chem_utilities.F

TESTS CONDUCTED: 
The Jenkins tests are all passing.

RELEASE NOTE: Fixed calculation of dry air density in module_chem_utilities.F. The bug had a very minor effect.

Might be warnings in the rest of the code, and I might need to increase
the stack size again, but it compiles without error.